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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). 
Abstract 


This document serves to register and document the standard MIME types 
associated with the 3GPP multimedia file format, which is part of the 
family based on the ISO Media File Format. 


1. Introduction 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


The third-generation partnership project (3GPP) for third-generation 
cellular telephony has defined a standard file format to contain 
audio/visual sequences which may be downloaded to cellular phones 
[3GPP]. At the time of writing, the 3GPP file format (3GP) can 
contain H.263 or MPEG-4 video, and AMR Narrow-band speech, AMR wide- 
band speech, or AAC audio, and 3GPP timed text. 


Within the file, as with all files in the ’ISO’ family, there is an 
intrinsic file-type box, which identifies those specifications to 
which the file complies, and which players (possibly compliant with 
only one specification) are permitted by the content author to play 
the file. This identification is through four-letter ’brands’. 
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Files identified by the MIME [MIME1] type defined here MUST contain a 
brand defined in a standard issued by 3GPP that can apply to 3GPP 
files, in their compatible brands list. 


The MIME types defined here are needed to correctly identify such 
files when they are served over HTTP, included in multi-part 
documents, or used in other places where MIME types are used. 


2. Security Considerations 


The 3GPP file format may contain audio, video, and displayable text 
data. There is currently no provision for '’active’ elements (such as 
scripts) of any kind. 


Clearly it is possible to author malicious files which attempt to 
call for an excessively large picture size, high sampling-rate audio 
etc. However, clients can and usually do protect themselves against 
this kind of attack. 


It should be noted that selected metadata fields may encompass 
information partly intended to protect the media against unauthorized 
use or distribution. In this case, the intention is that alteration 
or removal of the data in the field would be treated as an offense 
under national agreements based on World Intellectual Property 
Organization (WIPO) treaties. 


3GPP files have an extensible structure, so that it is theoretically 
possible that metadata fields or media formats could be defined in 
the future which could be used to induce particular actions on the 
part of the recipient, thus presenting additional security risks. 
However, this type of capability is currently not supported in the 
referenced specification. 


There is no current provision in the standards for encryption, 
signing, or authentication of these file formats. 


3. MIME Types 
This registration applies to all files defined as using the ’3GP’ 
file format and identified with a suitable brand in a 3GPP 
specification. The usual file suffix for all these files is ".3gp". 


3.1. Files with audio but no video 


The type "audio/3gpp" may be used for files containing audio but no 
visual presentation (neither video nor timed text, for example). 
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To: ietf-types@iana.org 
Subject: Registration of Standard MIME media type audio/3gpp 


MIME media type name: audio 
MIME subtype name: 3gpp 
Required parameters: none 
Optional parameters: none 


Ongoing work related to this 
registration may introduce new 
optional parameters. One example 
area of effort may introduce a 
parameter that would allow for 
codecs in use within the MIME type 
to be asserted and determined 
without examination of the file. 
Those with interests in the area 
should monitor registrations for 
updates. 

Encoding considerations: files are binary and should be 
transmitted in a suitable encoding 
without CR/LF conversion, 7-bit 
stripping etc.; base64 is a suitable 
encoding. Note that this MIME type 
is used only for files; separate 
types are used for real-time 
transfer, such as for the RTP 
payload format for AMR audio 


[RFC3267]. 

Security considerations: see the security considerations 
section in RFC 3839 

Interoperability considerations: The 3GPP organization has defined the 


specification, interoperability, and 
conformance, and conducts regular 
interoperability testing. 

Published specification: 3GPP 26.234, Release 5; 3GPP 26.244, 
Release 6 or later. 3GPP 
specifications are publicly 
accessible at the 3GPP web site, 
www.3gpp.org. 

Applications which use this media type: Multi-media 

Additional information: The type "“audio/3gpp" MAY be used for 
files containing audio but no visual 
presentation. Files served under 
this type MUST NOT contain any 
visual material. (Note that 3GPP 
timed text is visually presented 
and is considered to be visual 
material). 
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Magic number(s): None. However, the file-type box 
must occur first in the file, and 
MUST contain a 3GPP brand in its 
compatible brands list. 


File extension(s): 3gp and 3gpp are both declared at 
http://www.nist.gov/nics/; 3gp is 
preferred 

Macintosh File Type Code(s): '3gpp’ 


Person & email address to contact for further information: 

Nokia MIME manager, mime@nokia.com 
Intended usage: COMMON 
Change controller: 3GPP 


3.2. Any files 


The type "video/3gpp" is valid for all files. It is valid to serve 
an audio-only file as "video/3gpp". 


To: ietf-types@iana.org 
Subject: Registration of Standard MIME media type video/3gpp 


MIME media type name: video 
MIME subtype name: 3gpp 
Required parameters: none 
Optional parameters: none 
Encoding considerations: files are binary and should be 


transmitted in a suitable encoding 
without CR/LF conversion, 7-bit 
stripping etc.; base64 is a suitable 
encoding. Note that this MIME type 
is used only for files; separate 
types are used for real-time 
transfer, such as for the RTP 
payload formats for H.263 

[RFC2429] and AMR audio 


[RFC3267]. 

Security considerations: see the security considerations 
section in RFC 3839 

Interoperability considerations: The 3GPP organization has defined the 


specification, interoperability, and 
conformance, and conducts regular 
interoperability testing. 

Published specification: 3GPP 26.234, Release 5; 3GPP 26.244, 
Release 6 or later. 3GPP 
specifications are publicly 
accessible at the 3GPP web site, 
www.3gpp.org. 

Applications which use this media type: Multi-media 
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Additional information: 

Magic number(s): None. However, the file-type box 
must occur first in the file, and 
MUST contain a 3GPP brand in its 
compatible brands list. 


File extension(s): 3gp and 3gpp are both declared at 
http://www.nist.gov/nics/; 3gp is 
preferred 

Macintosh File Type Code(s): '3gpp’ 


Person & email address to contact for further information: 

Nokia MIME manager, mime@nokia.com 
Intended usage: COMMON 
Change controller: 3GPP 


4. IANA Considerations 


This document registers the MIME types audio/3gpp and video/3gpp, 
defined above. 
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8. Full Copyright Statement 


Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78, and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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